I think your right. This was there for the windows prompt

Should I change it only display on Windows in that case, and not for any other platform?

Actually yes that would be a better fix @gary-sweet

Can we extend this to "Don't ask to press return at the end of showing help on terminals"? This might be fine if you run the binary from e.g. the explorer, but it's acting very weird if you run it from e.g. Windows terminal. You need to press a key after the help shows up, and the terminal prompt is then continuing in the middle of nowhere:

Can we extend this to "Don't ask to press return at the end of showing help on terminals"? This might be fine if you run the binary from e.g. the explorer, but it's acting very weird if you run it from e.g. Windows terminal. You need to press a key after the help shows up, and the terminal prompt is then continuing in the middle of nowhere:

I'm not sure how anything I've changed here can affect this. The same code should be running on Windows platforms as it always was.

Sorry, should've noted that this was caused by the change in #956. I think if we remove the key press requirement on Windows too, the odd behaviour goes away.

Can we extend this to "Don't ask to press return at the end of showing help on terminals"?

To make it a bit more complex, this seems to depend on the terminal! I get different behaviours on different terminals (on Win10):

• with the simple command window, I have to enter return, no matter if std::cin.get() is called or not! But the next prompt is right after the help-output.
• with the PowerShell, I also have to enter return, no matter if std::cin.get() is called. And the next prompt is right after the previous prompt. That is: at the beginning of the help text!
• with a bash terminal, if std::cin.get() is not called, everything is as expected: you don't need to enter any key and the next prompt is right after the help-output.

That is, even though it seems you could reliably determine if the program has been started from any of those terminals, due to their different and partly strange behaviours it doesn't seem to be worth to make it so.

HWND consoleWnd = GetConsoleWindow();
DWORD consoleProcessId;
GetWindowThreadProcessId(consoleWnd, &consoleProcessId);
if (GetCurrentProcessId() == consoleProcessId)

I can't test anything on Windows, so if we believe this needs a different behaviour there I'm afraid someone else will have to implement it. I don't see any reason that should prevent this PR going ahead though - any further change can be done on top of it.

You're correct. Let's move the Windows related discussion to the PR or a new issue. Sorry for the noise.